-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8340547: Starting many threads can delay safepoints #1365
Conversation
👋 Welcome back snazarki! A progress list of the required criteria for merging this PR into |
❗ This change is not yet ready to be integrated. |
This backport pull request has now been updated with issue from the original commit. |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a reviewer but took a look since it was my original patch. Looks good to me.
src/hotspot/share/prims/jvm.cpp
Outdated
@@ -2955,9 +2955,10 @@ JVM_ENTRY(void, JVM_StartThread(JNIEnv* env, jobject jthread)) | |||
// We must release the Threads_lock before we can post a jvmti event | |||
// in Thread::start. | |||
{ | |||
MutexLocker throttle_ml(UseThreadsLockThrottleLock ? ThreadsLockThrottle_lock : NULL); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be nullptr
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't catch the NULL use, thanks for fixing it.
|
/approval request I'd like to backport this fix to eliminate the performance penalty measured in large thread pools. Some users find this as a blocker for transitioning from JDK8. |
@snazarkin |
/approval request I'd like to backport this fix to eliminate the performance penalty measured in large thread pools. Some users find this as a blocker for transitioning from JDK8. Revived by Paul Hohensee and Oli Gillespie(original author) |
@snazarkin |
@snazarkin This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
@snazarkin This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the |
I'd like to backport this fix to fix the issue with starting a lot of threads in a burst. Some users found this to be a barrier to migrating from JDK8.
The backport is not clean as required to adjust
globals.hpp
and replaceConditionalMutexLocker
with classicMutexLocker
. Original fix and discussion are hereTested with
tier1
and reproducers from JDK-8340547, JDK-8307970Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk21u-dev.git pull/1365/head:pull/1365
$ git checkout pull/1365
Update a local copy of the PR:
$ git checkout pull/1365
$ git pull https://git.openjdk.org/jdk21u-dev.git pull/1365/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1365
View PR using the GUI difftool:
$ git pr show -t 1365
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk21u-dev/pull/1365.diff
Using Webrev
Link to Webrev Comment